在 Vibe Coding 的過程中，每多接一個服務，就很有可能多一份帳單。

網站做到這裡，已經用了十幾個服務：網域、部署、資料庫、寄信、監控、分析……仔細一看，其中大部分都是免費的。

但天下沒有白吃的午餐。這些免費方案，有不少是「先讓你用，用多了再收費」：自己玩玩的時候綽綽有餘，一旦流量起來，很容易就超出額度，帳單也跟著出現。

身為一個精打細算的客家人，今天就來清點這趟旅程目前已經ㄒ消耗的口糧：現在每個月花多少、哪些地方未來可能變貴，又有哪些方法能夠讓自己的網站撐得更久。

一、目前花了多少錢

把第一天到現在用過的服務列出來：

這張表裡有兩種不同的花費：

• 固定成本：每個月不管有沒有人來，都要付。例如 Vercel Pro、AI 工具的訂閱。
• 按用量計費：用多少付多少，或是超過免費額度才開始收費。例如流量、寄信數量、錯誤數量。

固定成本好預估，難的是按用量計費。網站突然爆紅、被爬蟲大量造訪，或是程式出錯一直重試，帳單都可能暴增。有些平台可以設定用量通知，避免收到帳單時才嚇一跳。

二、網站可以怎麼賺錢

文章中實作的專案目前是一個公開的查詢網站，最簡單直接的方式是廣告，未來再加上付費會員可以去掉廣告，或是推出真的很實用的進階功能，吸引使用者付費。

廣告設定起來不麻煩，但收入相對少，除非網站的流量真的很高。很多訂閱制服務都把「去廣告」當成會員福利之一，但老實說，只靠去廣告很難讓人掏錢，通常還要搭配更進階的功能，或是直接賣實體商品。

今天的文章會先以用得到的概念為主，依照我在其他專案的開發經驗，分別說明金流和廣告各自要準備什麼，有些範例會用我在其他專案中的經驗來提及。

三、金流

3.1 為什麼要用第三方金流

如果自己直接處理、傳輸或儲存信用卡資料，就要符合非常嚴格的安全規範（PCI DSS），責任與安全負擔都會大幅增加。一旦外洩，後果非常嚴重。

另一種看似簡單的做法，是直接讓使用者轉帳到自己的銀行帳戶。但短時間內大量、小額、跟平常使用習慣不同的轉帳，可能被銀行視為異常交易，要求說明，甚至限制部分功能。

所以比較常見的做法，是交給第三方金流：使用者在金流公司的頁面輸入卡號，你的網站只會收到「這筆付款成功了」的通知，從頭到尾碰不到卡號。

用餐廳來想，餐廳不會自己發行信用卡、也不會保管客人的卡號，而是跟銀行租一台刷卡機。

3.2 常見的第三方金流服務

幾個選擇時的重點：

• 個人 vs 公司：這次比較的幾家台灣金流都提供個人申請方式，但個人會員的收款額度通常比較低，部分付款方式也只開放給公司。隨著交易量或功能需求增加，可能需要轉成企業會員。
• 電子發票：要不要開發票、開哪一種，取決於你的營業登記與稅籍身分，這是很容易被忽略的一環。如果需要開發票，能和金流一起串接會省很多事。
• Stripe：串接體驗是業界公認的好，但對台灣開發者來說，最大的門檻不是串接，而是公司設立在哪裡：台灣目前不是 Stripe 正式支援的地區。如果本來就有美國等支援地區的公司，才比較適合考慮。

3.3 申請與審核

金流公司的審核，不只看身分文件，也會看你的網站。常見的要求：

• 有實際的商品或服務頁面，而且標示價格
• 退換貨政策
• 聯絡方式、客服資訊
• 隱私權政策
• 販售實體商品的話，還要有出貨說明

也就是說，送審前網站要先「看起來像一個真的在做生意的網站」，才比較容易過審。個人申請不需要公司名稱與統編，但需要身分證明和收款帳戶。

我自己的申請經驗

• 綠界：審核比較快（2~3天），但要附的資料相對比較多。除了網站內容，還要求提供實體商品的庫存照片、辦公室照片等證明。
• 統一金流：審核沒那麼嚴格，但最近審核時間變得很久（數十天～數月），要提早申請。

審核標準會隨時間調整，以上是我申請時的經驗，僅供參考。

此外，針對虛擬商品，我個人體感綠界應該更嚴格，他們官網也有提到如果商品與生成式 AI 、點數、票卷相關，會需要申請特約賣家，資格會更嚴格。

3.4 一筆付款是怎麼完成的

【圖 1｜一筆付款的完整流程（以付費會員開通進階權益為例）】

這張圖裡有幾個概念：

冪等性跟 Day 26 的競態條件有點像，都是「同一件事可能不只發生一次」時會出問題；不同的是，競態條件在意的是「同時發生」，冪等性在意的是「重複發生」。

導回的頁面是給使用者看的；真正改變訂單狀態，要靠後端驗證過的付款結果。

這整個流程，背後還需要透過後端、資料庫去驗證、確認、記住幾件事：

金流公司只負責「收錢」，訂單、權益這些狀態，都要自己的網站記錄和管理。

如果通知一直沒來呢？各家金流通常都有「查詢交易」的 API，可以主動去問某筆訂單的狀態。定期主動核對，就是「對帳」。

金鑰的處理跟 Day 26 一樣：不能加 NEXT_PUBLIC_、不能 commit、不能貼給 AI，只放在伺服器的環境變數。

3.5 串接與沙盒測試

金流的串接細節很多：參數格式、簽章演算法、各種狀態碼。這正是 AI 擅長的地方。我自己的做法有兩種：

• 把官方文件交給 AI：把金流的 API 文件丟給 AI，請它依文件串接。
• 使用現成的 skill：綠界在 GitHub 上提供了官方的 API skill；也有人整理了涵蓋綠界、藍新、統一的 paid-tw 這組 skill。套用之後，AI 就知道參數格式和簽章怎麼算，開發會快很多。延續 Day 26 的原則：裝之前先讀過內容。

交給 AI 串接時，有幾件事一定要守住：

AI 有可能會寫出 「在使用者導回成功頁時更新訂單」 這種直覺的流程，因為那是測試時最容易看到的地方。但真正可靠的，是背景通知。

串接完，就用沙盒測試。每家金流都有測試環境，可以用測試卡號跑完整個付款流程，不會真的扣款：

測試時有一個很常見的坑：本機的 localhost 收不到 webhook。 圖１中的第 5 步是金流公司從外面連進你的伺服器，它連不到你電腦裡的 localhost。所以這方面的測試需要部署到 Vercel 的 Preview，或是用之前提過的 ngrok，開一個外面連得到的網址。

跟設定 Supabase Redirect URL 道理一樣：用 ngrok 測試時，網址可能每次啟動都不同，金流的通知網址也要跟著換。

金流的部分先寫到這裡。想實際串接的讀者，可以從申請沙盒帳號開始，照著上面的流程，用 Preview 環境跑一次付款，確認 webhook 收得到、簽章驗得過、訂單狀態有更新。

測試時用的是測試環境的金鑰和網址；上線前，要記得換成正式環境的。這時候 Vercel 區分 Production、Preview 環境變數的功能就很實用：Preview 放測試金鑰，Production 放正式金鑰。

3.6 物流

賣實體商品的話，還要考慮出貨：

部分金流公司本身就整合了物流。以超商取貨為例，流程大概是這樣：

【圖 2｜成立超商取貨訂單的流程】

跟金流一樣，物流狀態的變化通常也是靠背景通知（webhook）或查詢 API 取得，同樣要驗證、要能承受重複通知。

門市選擇通常不用自己手刻，物流服務會提供電子地圖，網站要做的是「跳過去、把選好的門市收回來」。但訂單列表、狀態顯示、出貨管理這些介面，就要自己做了。

我自己串物流的經驗

我之前開發一個販售實體商品的網站時，申請並串接物流的小心得：

• 綠界：申請金流時，可以同時送出物流的申請。
• 統一：物流需要另外寄信申請開通，同時需要一個固定的伺服器 IP 來回傳資料。部署在 Vercel 要特別注意，Vercel 預設的對外 IP 不是固定的，要另外處理。

物流牽涉的狀態比金流多很多：寄件、到店、取貨、未取退回……如果只是賣數位商品或會員，可以先不用考慮。

另外，如果只是想賣商品，不一定要自己架網站：不少金流商也提供現成的開店服務，用起來很方便，只是客製化的彈性比較少。

四、Google AdSense

4.1 送審

AdSense 要先審核網站，通過後才能顯示廣告。審核會看：

• 內容：原創、有價值，而且有一定的量。內容不足或整體價值不明確，是常見的被拒原因之一。
• 政策頁面：隱私權政策、聯絡方式。
• 網站驗證：證明網站是你的。方式是在網站放一段 AdSense 程式碼，或是放 ads.txt。

所以加完程式碼或是ads.txt之後，也需要重新部署，才會生效。（有一點類似昨天提到的GA4，但是GA4不需要審核，放上程式碼就自動追蹤流量；Google Adsense 則是會需要一段時間來審核。）

ads.txt 是放在網站根目錄的一個文字檔，公開宣告「誰有權在這個網站賣廣告」，防止別人冒用你的網站賣假廣告。它不是強制的，但 Google 強烈建議設定，也可以拿來驗證網站。在 Next.js 裡，放在 public/ads.txt 就好。

審核通常要幾天到幾週。

我個人的經驗大概是3~5天左右。

4.2 自動廣告 vs 手動放置

Google 的廣告可以分成自動或手動兩種：

自動廣告也不會是強制全開或全關：可以在後台設定排除特定頁面或特定區塊，也可以先用實驗功能只對部分流量測試。

不管哪一種，都要注意 Day 27 的 CLS（畫面跳動）：廣告通常比內容晚載入，突然出現時會把下面的內容往下推。手動放置時，要先預留廣告的空間，例如固定區塊的高度，讓廣告載入時不會推動其他內容。

4.3 Offerwall 與獎勵式廣告

AdSense 的 Offerwall 在 2026 年 4 月全面開放：訪客瀏覽一定數量的頁面後，會看到一個選擇，例如完整看完一段廣告後，換取繼續瀏覽的權限。設定在 AdSense 的「隱私權與訊息」裡。

也有另外一種是自訂的獎勵式廣告，可以自行透過程式碼去設定說看完廣告可以獲得網站內的某項福利（例如解鎖某一篇文章閱讀權限）通常是和訪客願意為了繼續看而付出一點時間代價的網站內容。相對於自動廣告來說，收益會比較高一點（因為使用者會看完。）

4.4 會員去廣告

付費會員不看廣告，是很常見的設計。實作上有兩個重點：

• 會員連廣告的程式碼都不要載入，而不是載入後再用 CSS 藏起來。藏起來的廣告一樣會拖慢速度，也可能違反廣告政策。
• 會員資格要由伺服器端確認，跟 Day 26 的原則一樣；前端再依確認過的會員狀態，決定要不要載入廣告。

這需要先有金流和會員權限，有興趣的可以自行去深入查詢。

4.5 隱私

加上廣告之後，隱私權政策要補上 AdSense：說明網站使用 Google 的廣告服務，可能會用 Cookie 顯示個人化廣告。

如果有歐洲等地區的訪客，Google 要求使用經過認證的 Cookie 同意工具，讓訪客選擇是否同意。這部分依網站的訪客來源決定。

換個領域

結語與明日預告

今天的新觀念：

網站要長久，不只要做得出來，還要養得起（沒錢是我的問題）。今天清點完口糧，也知道有哪些方法能讓開發過程中撐得更久。

從 Day 1 到今天，Vibe Coding 出來的網站已經不只是「做得出來」，而是開始變成一個真的能被使用、被維護，也需要被經營的產品。

明天，我們把這一路做過的事整理起來，也會提及幾個有點可惜沒能展開的主題。

我們明天見。